在前四天的 Helm 實戰中，我們認識到「平台級服務」這個概念。
今天，我們接著介紹 GitLab——一個集結多種需求的典型平台。

從程式碼管理、協作流程，到持續整合與部署，GitLab 將分散的工具與職能集中在同一個系統中，讓開發與維運得以在同一舞台上協作。
理解 GitLab 如何串連整個流程，是掌握自動化交付的關鍵第一步。

GitLab CI 的三個核心角色

在 GitLab CI 的世界裡，有三個核心角色：

1. GitLab Server

在大多數團隊中，Server 由平台維運團隊負責，我們身為使用者不需要碰伺服器細節。
它主要負責三件事：

1. 接收程式碼推送（Git Push / Merge Request）
2. 根據 .gitlab-ci.yml 解析 Pipeline 流程
3. 將工作派發給 Runner

Server 只負責「安排工作」，不執行實際任務。

2. GitLab Runner

Runner 就像是一組工人，你的 Pipeline Job 是一張「工單」。

在我的團隊中，我們透過 Helm 將 Runner 部署在 GKE（Google Kubernetes Engine） 上：

• 每個 Runner 以 Pod 的形式運行
• 副本數會依即時 Pipeline 任務量自動擴縮
• Kubernetes 幫助資源隔離、回收與彈性擴展

這樣的設計讓 CI/CD 能自動隨需求伸縮，避免因單一節點瓶頸而造成排程延遲。

3. .gitlab-ci.yml

所有 Pipeline 規劃，都寫在 .gitlab-ci.yml 這份設定檔中。
它描述：

• Stage：流程的高層次階段，例如 Build → Test → Deploy
• Job：每個 Stage 中的具體任務
• Image：執行 Job 的容器環境
• Variables：跨 Stage 的環境變數或敏感資訊
• Workflow：控制整個 Pipeline 是否觸發
• Rules：控制單一 Job 是否執行

了解 .gitlab-ci.yml 的核心元素後，我們用一個簡單範例來具象化這些概念，展示 Workflow、Stage、Job、Image 與 Rules 如何協同運作，串連成完整的自動化流程。

範例：Workflow、Stage、Job、Image、Rules

# 定義 Pipeline 流程階段
stages:
  - build
  - test
  - deploy

# Workflow 控制整個 Pipeline
workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'  # 只在 main 分支觸發 Pipeline
      when: always
    - when: never                         # 其他分支不觸發

# Build 階段
build_job:
  stage: build
  image: node:18
  script:
    - npm install
    - npm run build

# Test 階段
test_job:
  stage: test
  image: node:18
  script:
    - npm test

# Deploy 階段
deploy_job:
  stage: deploy
  image: google/cloud-sdk:latest
  script:
    - gcloud app deploy
  rules:                  # Job Rules 控制部署 Job
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: always

概念說明

明白，我幫你把 Stage 執行流程這段整合到教學文範例之後，並提供幾個 Job 情境範例（Docker build、Terraform、Helm 部署），讓說明更具體。以下是整合後的段落：

範例中，Workflow 控制整個 Pipeline 的觸發，Stage 將流程拆解成清楚的階段，每個 Job 在指定的 Image 環境中執行，而 Rules 控制單個 Job 的執行條件。
接下來，我們來更細緻地觀察 Stage 的執行流程，理解 Runner 與 Image 的角色，以及 Job 在 Pipeline 中如何實際運作。

Stage 執行流程與 Job 執行環境

當某個 Stage 被觸發 時，Pipeline 流程會依 .gitlab-ci.yml 將 Stage 中的 Job 分派給 Runner 執行：

1. Server 與 Runner 角色

   • GitLab Server：負責中控與管理，解析 .gitlab-ci.yml，安排哪些 Job 需要執行。
   • GitLab Runner：真正執行 Job 的環境，接收 Server 派發的任務，可能是 Pod、VM 或裸機。

2. Runner 執行目錄

   • Runner 會在本地或容器中建立 工作目錄（Project Directory），包含專案程式碼與檔案。
   • Job 執行時，所有指令都在這個目錄下操作，例如打包、測試或產生部署檔。

3. Job 的執行容器（Image）

   • 每個 Job 可以指定 Image，Runner 會在該 Image 所提供的環境中執行命令。
   • Image 是 Job 的「乾淨執行環境」，確保工具版本與系統依賴一致。

4. 流程總結

   • Stage → 分派 Job → Runner 建立專案目錄 → 在指定 Image 容器中執行 Job → 回傳結果給 Server

這裡提供幾個範例，幫助各位更熟悉 Stage → Runner → Image → Job 的執行流程。

1. Docker Build

當 Server 分派 Job，Runner 啟動後，Runner 會看到該 Stage 的執行內容，並開始拉取指定的 Docker Image。
這裡我們使用 docker:dind 服務，使容器內可以調用 Docker Engine。Job 的 script 會在這個 Image 中執行：

docker_build:
  stage: build
  image: docker:24
  services:
    - docker:dind
  script:
    - docker build -t my-app:latest .

使用 Docker 官方 Image，Runner 提供資源，實際建構映像檔在 Image 中完成，專案目錄（含 Dockerfile）已被映射進容器。

2. Terraform 部署

Terraform Job 也在 Runner 提供的資源上執行，但真正的執行環境由指定 Image 提供：

terraform_apply:
  stage: deploy
  image: hashicorp/terraform:1.6
  script:
    - terraform init
    - terraform apply -auto-approve

使用 Terraform 官方 Image，Runner 提供硬體與目錄映射，所有 Terraform 初始化與套用操作在 Image 中完成。

3. Helm 部署

在 Helm 部署情境中，Job 在全新建立的 Image 中執行。記得在容器中完成 GKE 認證，才能進行 Kubernetes 部署：

helm_deploy:
  stage: deploy
  image: alpine/helm:3.12
  script:
    - gke get credential
    - helm repo add bitnami https://charts.bitnami.com/bitnami
    - helm upgrade --install my-app bitnami/nginx

Helm 官方 Image 提供完整工具環境，Runner 僅提供資源與專案目錄映射，真正的 Job 執行環境由 Image 決定。

未熟悉的使用者可能會誤解為專案及腳本的動作直接在 Runner 上執行。實際上：

Project -> Runner（資源提供） -> Image（執行環境） -> script

Runner 只是執行資源（CPU、記憶體、工作目錄）的提供者，而 Job 的執行邏輯、所需工具與環境都由 Image 決定。

小結

今天我們從 GitLab CI 的核心角色切入，完整解析了 Server、Runner 與 .gitlab-ci.yml 的定位與責任：

• Server：負責中控與管理，安排 Pipeline 流程，但不直接執行任務。
• Runner：提供執行資源與專案目錄映射，是真正執行 Job 的環境。
• Image：決定 Job 的執行環境與工具版本，確保每個任務在乾淨、一致的環境中運行。

透過範例，我們理解了 Workflow、Stage、Job、Image、Rules 如何協同運作，從程式碼推送到任務執行，Pipeline 的每個步驟都被拆解並自動化管理。

Docker Build、Terraform 與 Helm 部署的範例，也讓 Runner 與 Image 的角色更加具象化：Runner 提供資源，Image 才是真正執行 Job 的環境。這些理解將幫助你在實務中更順利地設計與管理 CI/CD 流程。

透過核心角色的介紹與 Stage 流程的說明，相信各位已經對 Pipeline 有了基本概念，也為後續的 參數注入、變數運用與參數管理技巧 做好鋪墊。

感謝各位閱讀，我們明天見！